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This is an Appeal Brief under 37 C.F.R. § 41.37 in connection with a Final 
Office Action mailed on May 31, 2006. Each of the topics required by Rule 41.37 is 
presented herewith and is labeled appropriately. The Notice of Appeal was filed on 
November 30, 2006. 

(1) Real Party in Interest 

The real party in interest is Citicorp Development Center, Inc., having an 
office at 12731 West Jefferson Boulevard, Los Angeles, California 90066. 

(2) Related Appeals and Interferences 

Appellants are unaware of any related appeals and interferences. 

(3) Status of Claims 

Claims 1 and 3-48 are pending in this application. Claims 1-48 stand under 

final rejection, from which rejection this appeal is taken. 
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(4) Status of Amendments 

The claims have not been amended after the final Office Action dated 
November 30, 2006. 

(5) Summary of the Claimed Subject Matter 

The summary of the claimed subject matter is a concise explanation of the 
subject matter defined in independent claims 1,18, 25, 37, and 45. This is merely 
meant to be a summary and is in no way intended to limit the pending claims. 

In an embodiment as recited in claim 1 , a system for performing a financial 
transaction, comprises a first electronic application for storing application-specific 
value ( See Fig. 3, ref. num. 118) on a transaction card ( See Fig. 2, ref. num. 12); a 
second electronic application for storing general value ( See Fig. 3, ref. num. 1 16) on 
the transaction card; and a transaction application associated with at least said first 
electronic application for performing a value exchange ( See Fig. 3, ref. nums. 122, 
124), wherein said application-specific value and said general value are each 
exchangeable between each other in said transaction application; and wherein said 
application-specific value and said general value are each compatible within said 
system for performing said financial transaction. See, e^g., page 4, lines 18-28; page 
5, lines 5-7; page 12, lines 1-7. 

In an embodiment as recited in claim 18, a smart card ( See Fig. 2, ref. num. 
12) for performing a financial transaction, comprises a first application for storing 
application-specific value ( See Fig. 3, ref. num. 118) on said smart card; a second 
application for storing general value ( See Fig. 3, ref. num. 116) on said smart card; 
wherein said application-specific value and said general value are each compatible for 
performing said financial transaction; and wherein said application-specific value and 
said general value are each exchangeable ( See Fig. 3, ref nums. 122, 124) between 
each other . See, e^g,, page 4, lines 18-28; page 5, lines 5-7; page 12, lines 1-7. 

In an embodiment as recited in claim 25, a method for performing a financial 
transaction with a smart card ( See Fig. 2, ref num. 12), comprises storing application- 
specific value ( See Fig. 3, ref num. 1 18) in a first electronic application on said smart 
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card; storing general value in a second electronic application on said smart card; 
performing a value exchange associated with the financial transaction, wherein the 
application-specific value and the general value are each exchangeable between each 
other in the financial transaction. See , e.g. , page 5, lines 5-7; page 12, lines 1-7. 

In an embodiment as recited in claim 37, a method for performing a financial 
transaction for exchanging an amount of value between a smart card ( See Fig. 2, ref. 
num. 12) and a corresponding device ( See Fig. 4, ref. num. 94), comprises providing 
application-specific value ( See Fig. 3, ref. num. 1 18) and general value ( See Fig. 3, 
ref. num. 116) on the smart card, where both the application-specific value and 
general value are compatible for use in performing the financial transaction and 
wherein the application-specific value and the general value are each exchangeable 
between each other; and exchanging a transaction amount of value between the smart 
card and the corresponding device, where the transaction amount of value is at least a 
portion of one of the application-specific value and the general value. See , e.g. , page 
5, lines 5-7; page 12, lines 1-7. 

In an embodiment as recited in claim 45, a system for performing a financial 
transaction, comprises a smart card ( See Fig. 2, ref. num. 12) having a memory (See 
Fig. 1, ref. num. 48) for storing a first application having application-specific value 
( See Fig. 3, ref. num. 118) and a second application having general value ( See Fig. 3, 
ref. num. 116), wherein said application-specific value and said general value are 
compatible for performing said financial transaction and wherein said application- 
specific value and said general value are each exchangeable between each other and 
are secured by encryption on said smart card; and a purchase device ( See Fig. 4, ref 
nums. 94, 96) for removing value from said smart card, said purchase device 
comprising a first purchase key ( See Fig. 4, ref num. 30) for use in removing 
application-specific value from said first application and a second purchase key ( See 
Fig. 4, ref num. 28) for use in removing general value from said second application, 
wherein both said first and second purchase keys are security mechanism for 
accessing encrypted information, and wherein said purchase device is adapted for 

communication with said smart card to transfer at least one of said application- 
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specific value and said general value in said financial transaction. See, ej^, page 5, 
lines 14-21; page 6, lines 1-13; page 12, lines 1-7. 

The term "general value" is defined to include, for example, value that is 
generally equivalent to cash in that the general value is readily accepted in a plurality 
of financial transactions, and the term "application-specific value" is defined to 
include, for example, value that has limited acceptance, typically only for transactions 
associated with a specific application loaded onto the smart card. General value may 
be accessed by a specific application program and converted into application-specific 
value, and similarly, application-specific value may be able to be converted to general 
value. See, e.g. , page 7, lines 19-25. 

(6) Issues 

A. Whether the Examiner's rejections of claims 1-48 under 35 U.S.C. § 
1 12, first paragraph, and 35 U.S.C. §112, second paragraph, is proper. 

B. Whether the Examiner's rejection of claims 1, 3-35, 37-42, and 44-48 
under 35 U.S.C. § 103(a) is proper. 

C. Whether the Examiner's rejection of claims 36 and 43 under 35 U.S.C. 
§ 103(a) is proper. 

(7) Argument 

A. The Examiner's rejection of claims 1-48 under 35 U.S.C. § 112, 
first paragraph, and 35 U.S.C. § 112, second paragraph, is 
improper. 

Claims 1-48 are rejected under 35 U.S.C. § 112, first paragraph, as failing to 

comply with the written description requirement. Claims 1-48 are also rejected under 

35 U.S.C. § 1 12, second paragraph, as being indefinite for failing to particularly point 

out and distinctly claim the subject matter which applicant regards as the invention. 

The undersigned representative notes that claim 2 has been previously canceled and 

only claims 1 and 3-48 were pending at the time of the Office Action. Accordingly, 

the undersigned representative will apply the rejections to claims 1 and 3-48, but asks 

again that the rejection be withdrawn with respect to claim 2. 
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The rejections of claims 1 and 3-48 under § 112 both stem from the 
Examiner's confusion with regard to the terms "general value" and "application- 
specific value." The Examiner does not appear to understand (1) what each of these 
terms mean, including the metes and bounds of each value, (2) how general value and 
application-specific value can be exchanged, and (3) how general value and 
application-specific value can be compatible. Accordingly, and in an effort to 
simplify the issues by addressing both rejections under § 112 simultaneously, the 
undersigned representative will again show the differences between these terms and 
how the values can be exchanged or compatible. 

1. The Definitions of "General Value" and "Application- 
Specific Value" 

In the Final Office Action, the Examiner asserts that the claims contain subject 
matter which was not described in the specification in such a way as to reasonably 
convey to one skilled in the relevant art that the inventors, at the time the application 
was filed, had possession of the claimed invention. Specifically, the Examiner 
asserts: 

There is recited in the independent claims "application-specific value" 
and "general value." These separate recitations are further recited as 
stored on separate "electronic applications." A lack of written 
description appears to be present because there is further recited in the 
independent claims an exchangeability and compatibility which would 
not allow one with ordinary skill in the art at the time the application 
was filed to distinguish one type of value over the other , and therefore 
be able to practice the invention as claimed. 

Final Office Action at page 2 (Emphasis added). The Examiner asserts that "There is 

recited in the independent claims 'application-specific value' and 'general value 5 . 

The meets (sic) and bounds are not clear for each type of value to that the recitations 

are vague and indefinite, especially since there is also claimed an exchangeability and 

compatibility between the two values." Id. at page 3. In the Examiner's Response to 

Arguments of the Office Action, the Examiner states: 

Applicant's argument filed 6-21-05 have been fully considered but they 
are not persuasive regarding the 35 U.S.C. 1 12, 2 nd paragraph rejection. 
The terms "readily accepted", "generally accepted", "typically", and 
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"may" in the description on page 7, lines 19-29 of applicant's 
specification does not preclude a general value to include application 
specific value and vice versa. Since applicant's arguments regarding 
the prior art is with regards to the distinction between general and 
application specific value, the 35 U.S.C. 103 rejection is maintained. 

Office Action at page 10. 

The terms "general value" and "application-specific value" are clearly 

described in the specification and are distinguishable from each other. The 

specification defines "general value": 

The term "general value" comprises value that is generally equivalent 
to cash in that the general value is readily accepted in a plurality of 
financial transactions . 

Page 7, lines 19-20 (emphasis added). The specification also defines "application- 
specific value": 

The term "application-specific value" comprises value that has limited 
acceptance, typically only for transactions associated with a specific 
application loaded onto the smart card. 

Page 7, lines 21-23 (emphasis added). Thus, based upon even just these definitions in 
the specification, it is apparent that a general value acts like cash whereas an 
application-specific value is more limited in that it is associated with a specific 
application. 

A "general value" is accepted in a plurality of financial transactions. General 
value is similar to cash in that it can be used for a variety of purposes, including 
various applications and/or locations. Claim 1 recites, for example, "a second 
electronic application for storing general value on the transaction card." According to 
the description of the present application, "Open purse application 28 is an 
application that stores general value 32 that may be accessed by other applications to 
pay for all types of goods and services ." Page 12, lines 9-10 (emphasis added). 
Further, "Communications with open purse application 28 are in a common format, as 
is explained below, thereby allowing multiple external devices and applications to 
perform transactions utilizing the open purse application. Examples of a suitable 
open purse application 28 include VISA CASH® payments, Mondex® payment 
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systems, and other similar applications that provide for the storage and exchange of 
general value." Page 12, lines 13-18. Thus, general value is used similar to cash to 
pay for all types of goods and services, as described in detail in the written 
description. 

Unlike "general value," "application specific value" has only limited 
acceptance and cannot be used for all types of goods and services . Claim 1 recites, 
for example, "a first electronic application for storing application-specific value on a 
transaction card." According to the description of the present application, "Closed 
purse application 30 is an application that stores application-specific value 34 that 
may be accessed only by a specific application, or a limited number of specific 
applications, to pay for application-specific goods and services." Page 12, lines 20-22. 
"An example of closed purse application 30 is a metropolitan transit application 
(MTA) 74 having a transit purse 76 that stores transit value 78 that may be used to 
pay for transit services." Page 15, lines 8-10. In this particular example, the 
application-specific value can only be used for transit purposes. In contrast, the 
general value can be used for a variety of purposes, similar to the use of cash. 

With regard to the terminology used in the claims and the specification, 

general value differs from application-specific value. Yet the Examiner asserts that 

the "specification does not preclude a general value to include application specific 

value and vice versa." Office Action at page 10. But the specification does not 

suggest that a general value can include an application specific value or that an 

application specific value can include a general value. As described above, a general 

value is clearly distinct from an application specific value. The Examiner appears to 

be suggesting that a general value and an application specific value can encompass 

each other. While cash ( e.g. , general value) can be used for a transit system, value 

that is specific to use in the transit system ( e.g. , application-specific value) cannot be 

used as cash in other transactions. Although the general value and application 

specific value are both based on a monetary amount, the distinction between the two 

values regards the type of financial transaction where the value can be used. 

Although general value can be used in many types of transactions, the application 
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specific value can be used in only one particular type of transaction (hence 
"application-specific 1 '). 

The specification does not contradict the undersigned representative's 
explanation and does not support the Examiner's assertions. For example, the 
description recites, "The term 'general value' comprises value that is generally 
equivalent to cash in that the general value is readily accepted in a plurality of 
financial transactions." Page 7, lines 19-20 (emphasis added). The phrase "readily 
accepted," as recognized by one of ordinary skill in the art, provides for a broad scope 
of financial transactions without limiting the transactions to those expressly named in 
the present application. Although this recitation in the specification does not identify 
the "financial transactions," one of ordinary skill in the art would recognize when 
general value can be utilized for financial transactions. Accordingly, one of ordinary 
skill would recognize that the description of the present application sufficiently 
describes that the general value is not limited to a particular financial transaction. 

Other phrases identified by the Examiner further support this finding that 

broad terminology may be used in the description where it is evident that a general 

value is not limited to a particular transaction, unlike an application specific value. In 

another example, the description recites, "The term 'application-specific value' 

comprises value that has limited acceptance, typically only for transactions associated 

with a specific location loaded onto the smart card." Page 7, lines 21-23 (emphasis 

added). This recitation expressly states that application specific value has limited 

acceptance. The phrase "typically" is used to illustrate that the criteria for whether 

application-specific value is used can be determined by whether the particular 

transaction is associated with the application-specific value location on the smart 

card, but the the limited acceptance may be also based on other limitations. 

Nevertheless, it is clear that general value can be used for a variety of financial 

transactions and application specific value can be used for a particular kind of 

transaction. There is no indication, through the use of these phrases or other 

terminology, that the general value can include the application specific value or the 

application specific value can include the general value. 
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2. Exchanging Value between General Value and Application- 
Specific Value 

The specification provides sufficient written description on how "application- 
specific value and said general value are each exchangeable between each other in 
said transaction application/' as recited in claim 1. The ability to convert general 
value to application specific value or application specific value to general value is 
clearly explained and should not contribute to the Examiner's confusion. The 
"exchangeable" recitation of the claim finds exemplary support in the specification, 
which recites: 

General value may be accessed by a specific application program and 
converted into application-specific value. Alternatively, certain 
applications may limit or prohibit the conversion of their associated 
application-specific value to general value, such as entitlement program 
applications. Thus, while general value and application-specific value 
may be readily exchanged , the specific application program may 
provide specific rules governing the limits of the exchange . 

Page 7, lines 23-29 (emphasis added). In order to illustrate the exchange between 

general value and application specific value, consider an instance where cash ( e.g. , 

general value) is converted into a monetary amount for use in a transit system (ej^, 

application specific value). In such an instance, the value is being converted or 

exchanged such that the application of the value is going to be limited to a particular 

transaction. Alternatively, a value for a particular transaction (application-specific 

value) can be used for a variety of transactions (as general value). 

The specification provides an example involving exchangeability: 

In operation, referring to Fig. 3, a typical value exchange transaction 
utilizing system 10 and smart card 12 may comprise performing a 
financial transaction at a merchant, over the Internet, at a local terminal 
or with another cardholder utilizing a RWD [Reader - Writer Device] 
(block 100). A communication channel must be established between 
smart card 12 and the corresponding device (block 102). To establish 
the communication channel, the cardholder engages contact interface 
14 into contact RWD 18 (blocks 104 and 106) or places contactless 
interface 16 in proximity of contactless RWD 20 (blocks 108 and 110). 
A bi-directional communication then proceeds between card 12 and the 
respective RWD 18 or 20 that authenticates and verifies both the card 
the respective device (block 112). At this point, the cardholder may 
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indicate the amount of value involved in the financial transaction, such 
as if the cardholder is loading value onto the card or if a card-to-card 
value exchange is being performed (block 114). Alternatively, the 
cardholder may confirm the amount of value involved in the 
transaction, such as if utilizing card 12 in a merchant or Internet 
transaction. Similarly, this part of the transaction process may be 
implied, such as in transportation-related applications where a toll or 
fare may be charged depending upon distance traveled, time of day, 
customer status (i.e. senior citizen discount, preferred traveler), etc. 
Next, a choice may be made to utilize general value 32 from open purse 
application 28 or application-specific value 34 from closed purse 
application 30 (blocks 116 and 118). Again, this choice may be 
predetermined, depending on the application with which smart card 12 
is interacting. 

For example, in utilizing smart card 12 in a subway, the 
interacting RWD [Reader Writer Device] at an entry gate may 
automatically initiate a transportation application, such as MTA 74, and 
hence initially look to use application-specific value 34, such as transit 
value 38. In contrast, when inserting smart card 12 into a multi- 
functional terminal device having contact interface 14, the cardholder 
may be given a choice by the application program within the terminal 
device as to which type of value should be utilized. 

In either case, system 10 and the application program utilized 
inquire about the availability of sufficient value in the chosen 
application (block 120). If sufficient value exists, then the transaction 
is executed and the value exchange is performed and the transaction 
ends (blocks 122 and 124). If sufficient value does not exist, then the 
application may permit value from another closed or open purse 
application to be utilized (block 126). This option may be application- 
specific as some forms of value may not be convertible, or may have a 
limited ability to be converted. For example, application-specific value 
34 stored in a closed purse application 30 such as for entitlement 
programs, like a welfare program, may be restricted so that the value 
can only be used for transactions utilizing the closed purse application. 
If another application is permitted to be utilized, then the open or 
closed purse application may be chosen automatically, based on a pre- 
designation, or the cardholder may indicate which application to use 
(block 128). The value from the selected application may then be 
directly utilized to execute and end the transaction (blocks 130, 122 and 
124), or it may be converted to value to be stored in the initial 
application and then utilized to execute and end the transaction (blocks 
132, 122 and 124). Alternatively, if another closed or open purse 
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application is not chosen or permitted to be utilized, another option 
may be to perform the auto-load function, as described above (block 
134). If the auto-load is permitted and/or chosen, then value is added to 
the initial application and the transaction is executed and ended (blocks 
132, 122 and 124). If the auto-load is not permitted and/or not chosen, 
then the transaction is ended (block 124). Thus, system 10 provides a 
simple, convenient and fast value exchange transaction utilizing dual 
interface smart card 12. 

(emphasis added). Thus, the specification explains how "application-specific value 

and said general value are each exchangeable between each other in said transaction 

application," as recited in claim L 

3. Compatibility between General Value and Application- 
Specific Value 

The specification also provides sufficient written description for the premise 
that "application-specific value and said general value are each compatible within 
said system for performing said financial transaction," as recited in claim 1. The 
specification provides an example of compatibility: 

Another advantageous feature of the present invention is the integration 
of open purse application 28 and closed purse application 30 into a 
single system. As mentioned above, this is accomplished by 
structuring closed purse application 30 to be compatible with open 
purse application 28. Compatibility is enabled by structuring the data 
and transaction information for a particular closed purse application 30 
in a format compatible with the data and transaction information 
utilized by the particular open purse application 28 being utilized. An 
identification number associated with the card is preferably used to 
properly direct the closed purse application transaction information 
through the established back end computer systems 22 utilized by the 
particular open purse system application 28. 

Page 20, lines 17-26 (emphasis added). Thus, it is clear that compatibility between 
the general value and application-specific value, according to this exemplary 
embodiment, means that data regarding the general value and the application-specific 
value is in the same format. 

Therefore, as shown herein, the written description provides sufficient 
explanation for one of ordinary skill to distinguish between a "general value" and an 
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"application-specific value/' as well as an explanation of how the values are 
exchanged or compatible. Therefore, the undersigned representative respectfully 
requests that the Board reverse the Examiner's rejection of claims 1 and 3-48 under 
35 U.S.C. § 1 12, first paragraph and 35 U.S.C. §112, second paragraph. 

B. The Examiner's rejection of claims 1, 3-35, 37-42, and 44-48 under 
35 U.S.C. § 103(a) is improper. 

Claims 1, 3-35, 37-42, and 44-48 stand rejected under 35 U.S.C. § 103(a) as 
being unpatentable over Carlisle et al. (U.S. 5,649,118), in view of Derksen (U.S. 
5,478,993) and Gungl et al. (U.S. Pat. No. 5,912,453), and in further view of 
Electronic Payment Systems. Carlisle, Derksen, Gungl, and Electronic Payment 
Systems, alone or in combination, do not teach or suggest each and every limitation of 
the claims. 

1. The Examiner Recognizes Deficiencies in Carlisle 

Regarding independent claims 1,18, 25, 37, and 45, the Examiner recognizes 
that Carlisle fails to teach or suggest each and every claimed element including: (a) 
storing general value in an electronic application; (b) application-specific value and 
the general value each exchangeable with each other in a transaction application; (c) 
transfer includes at least a portion of each of said application-specific value and said 
general value; (d) new application-specific value is exchanged from said general 
value; (e) new general value loaded by the auto-load; (f) the settlement system 
additionally accounting for the flow of new general value; (g) new general value 
amount as the value for determining sufficiency; and (h) exchanging a deficient 
amount from: general value or from general value that was converted from 
application-specific value. Office Action at pages 6-7. In order to cure the many 
deficiencies of Carlisle, the Examiner relies on Derksen, Gungl, and Electronic 
Payment Systems. Furthermore, even by using all four references, the Examiner still 
needed to rely upon one of ordinary skill in the art to try to establish a teaching for the 
claims. As shown below, Derksen, Gungl, and Electronic Payment Systems do not 
cure the deficiencies of Carlisle, and, in some instances, actually teach away from the 
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goal of the present application. In this discussion, it is also evident that in view of all 
of these references, it is still not "obvious to one of ordinary skill in the art." 

Carlisle recites a smart card storing multiple accounts, such as Visa, 
MasterCard, Discover, ATM, food stamps, welfare, and unemployment accounts, and 
a look-up table that identifies the particular purchases that can be charged to a 
particular one of the accounts ( e.g. , non-food items cannot be charged to the food 
stamp account). As bar-coded items are scanned at a merchant POS terminal, the 
POS terminal refers to the look-up table to see which account to charge for each 
purchase. If the table indicates that a particular purchase can be charged to more than 
one account, the terminal charges a particular account or accounts according to a 
priority algorithm, or if the table does not provide an account for a particular 
purchase, the terminal again charges a particular account or accounts according to a 
priority algorithm, or manually via a keyboard selection. See, e.g. , Carlisle, Col. 1, 
line-Col. 2, line 67; and Col. 22, line 31 -Col. 24, line 18. Thus, Carlisle requires a 
"table" or "algorithm" to determine which account is used for a purchase. 

As already noted, the terms "general value" and "application-specific value", 
as recited in each of independent claims 1,18, 27, 37, and 45, are defined terms 
meaning, respectively, value that is generally equivalent to cash in that the general 
value is readily accepted in a plurality of financial transactions and value that has 
limited acceptance, typically only for transactions associated with a specific 
application program and converted into application-specific value. As conceded by 
the Examiner, Carlisle neither teaches nor suggests general value that is stored in a 
second electronic application on the smart card, in addition to the application-specific 
value stored in the first electronic application on the smart card, as recited in claims 1 , 
18, 27, 37, and 45. Just because Carlisle performs a transaction, it does not 
"inherently" recite general value that is stored in a second electronic application on 
the smart card and application-specific value stored in the first electronic application 
on the smart card, as the Examiner asserts. 

In fact, Carlisle teaches away from having both a first application with 

application-specific value and a second application with general value on the smart 
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card, as recited in claims 1,18, 27, 37, and 45. Carlisle associates with each data file 
an "account identifier for uniquely specifying a given account with an account 
balance and at least one item table identifier/' See , e.g. , Carlisle, Col. 2, lines 24-26. 
Thus, each account of each data file has a table listing items that such account can be 
used to purchase. See , e.g. , Carlisle, Fig. 12. Thus, it is clear that each of the multiple 
applications shown in Fig. 11 of Carlisle et al. stores only application-specific value 
( i.e. , a value for transaction of those particular items allowed and listed in an item 
table of each application). Therefore, Carlisle fails to teach or suggest each and every 
limitation. 

2. Derksen Fails to Cure Carlisle's Deficiencies 

Derksen fails to remedy the deficiencies of Carlisle. Neither Carlisle nor 
Derksen, either separately or in combination with one another, teach or suggest 
storing both general value application-specific value on the smart card, as recited in 
claims 1,18, 27, 37, and 45. Derksen recites a card storing different value limits in 
two or more "separate money compartments" which can each be used only at certain 
designated "payment sites" pursuant to certain "payment site arrangements." The 
"payment sites" include one to pay for services, including "public transport, tolls, and 
admission tickets," another that is likewise used for such payments and can also be 
reloaded, and still another that is also used for such payments, as well as "eating in 
certain restaurants" and can also establish on line contact with a verification agency 
for authentication and correction or reloading the card from an account of the card 
holder or debiting the card holder's account. See , e.g., Derksen, Col. 2, lines 35-37; 
Col. 4, lines 25-31; Col. 6, lines 47-50; and Col. 7, lines 9-25. 

Consequently, it is likewise clear that the "separate money compartments" of 
Derksen that can be used only at certain designated "payment sites" pursuant to 
certain "payment site arrangements" are only application-specific value for 
transactions at only those certain designated "payment sites" pursuant to those certain 
"payment site arrangements". Accordingly, the "separate money compartments" of 
Derksen store only application-specific values and not general values, and it is also 
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self-apparent that the "separate money compartments" of Derksen do not store both 
application-specific and general values. 

3. Gung] Teaches Away 

Gungl teaches away from storing both application-specific and general values 
on a transaction card, as recited in claims 1,18, 25, 37, and 45. Specifically, Gungl 
recites a chip card whereby "application programs which are stored on the chip card 
do not have access to each other." See, ejj., Gungl, Col. 3, lines 20-22 (emphasis 
added). Although there is language in Gungl about "communication" that may occur 
between independent units on a chip "when required" via a "control unit" ( See , e.g. , 
Gungl, Col. 3, lines 35-44), there is no suggestion in Gungl that application-specific 
value and general value are being exchanged. There is also language in the 
Background section of Gungl at Col. 2, lines 26-56 about prior art chip cards known 
as "multifunction or multifunctional chip cards," that are susceptible to an operator of 
an application program because he may "move feely" on the chip card. Accordingly, 
Gungl does not teach or suggest storing both an application-specific value and a 
general value on a transaction card, as recited in claims 1,18, 25, 37, and 45. 

4. Electronic Payments Systems Also Fails to Cure Deficiencies 
Electronic Payment Systems fails to remedy the deficiencies of Carlisle, 

Derksen, and Gungl. Carlisle, Derksen, Gungl, and Electronic Payment Systems, 

either separately or in combination with one another, neither teach nor suggest storing 

both general value application-specific value on the smart card which are each 

exchangeable with one another in a transaction, as recited in claims 1,18, 27, 37, and 

45. Section 7.2.8 of Electronic Payment Systems, relied on by the Examiner, recites: 

Another proposed extension is to allow customers to convert unspent 
tickets back to real money. This would be done by sending the ticket to 
the vendor, who would pay the remaining account balance to the user 
using an existing macropayment system. A system in which any user 
can accept payments, such as an electronic cash system will have to be 
used for this purpose. Credit card systems cannot do this. The cost of 
the macropayment transaction may have to be covered by the merchant 
charging a fee for the service. 
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It is noted that the context of the particular section of Electronic Payment 
Systems relates to "a simple micropayment protocol designed for efficient pay-per- 
view payments on the Internet" that "works by creating temporary prepaid accounts 
for users at a specific vendor." See , e.g. , Electronic Payment Systems, Section 7.2. 
Further, an "unspent ticket" referred to in Section 7.2.8 of Electronic Payment 
Systems is simply "a special account identifier used to authenticate the account owner 
to the account maintained at the vendor site in order to make a micropayment 
purchase" that "is valid only at one particular merchant." 

Electronic Payment Systems likewise teaches away from storing both general 
value and application-specific value on the smart card which are each exchangeable 
with one another in a transaction, as recited in claims 1,18, 27, 37, and 45, in that the 
"unspent ticket" is only application-specific value prepaid to an online merchant that 
"is valid only at one particular merchant." Moreover, refund of the unspent balance 
of the prepaid value by the merchant to the account owner in "[a] system in which any 
user can accept payments, such as an electronic cost system" which "[c]redit cards 
cannot do" has absolutely nothing to do with storing both general value application- 
specific value on the smart card which are each exchangeable with one another in a 
transaction, as recited in claims 1,18, 27, 37, and 45. 

Consequently, Carlisle, Derksen, Gungl, and Electronic Payment Systems, 
either alone or in combination with one another, do not teach or even suggest at least 
the required combinations of limitations proposing that both application-specific 
value and general value are stored on the transaction card and that the application- 
specific value and general value are each exchangeable with one another in a 
transaction, as recited in claims 1,18, 25, 37, and 45. Additionally, Carlisle, Derksen, 
Gungl, and Electronic Payment Systems, either alone or in combination with one 
another, do not teach or suggest at least the required combinations of limitations 
proposing that both application-specific value and general value are stored on the 
transaction card and that each is compatible within the system for performing a 
transaction, as recited in claims 1,18, 37, and 45. 
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Because the cited references, either alone or in combination, do not teach or 

suggest the limitations of independent claims 1,18, 25, 37, and 45, the Examiner has 

failed to establish the required prima facie case of unpatentability. See In re Royka , 

490 F.2d 981, 985 (C.C.P.A., 1974) (holding that a prima facie case of obviousness 

requires the references to teach all of the limitations of the rejected claim); See also 

MPEP §2143.03. Similarly, the Examiner has failed to establish a prima facie case of 

unpatentability for claims 3-16 that depend on claim 1, claims 19-24 that depend on 

claim 18, claims 26-36 that depend on claim 25, claims 38-44 that depend on claim 

37, and/or claims 46-48 that depend on claim 45, and which recite further specific 

elements that have no reasonable correspondence to the references. 

D. The Examiner's rejection of claims 36 and 43 under 35 U.S.C. § 
103(a) is improper. 

Claims 36 and 43 stand rejected under 35 U.S.C. 103(a) as being unpatentable 
over Carlisle et al. (U.S. 5,649,1 18), in view of (Derksen (U.S. 5,478,993) and Gungl 
et al. (U.S. Pat. No. 5,912,453)), in further view of Electronic Payment Systems as 
applied to the claims above, and further in view of Taskett (U.S. 5,991,748). 

As noted above, because Carlisle, Derksen, Gungl, and Electronic Payment 
Systems, either alone or in combination, do not teach or suggest independent claims 
25 and 37, the Examiner has failed to establish the required prima facie case of 
unpatentability of independent claims 25 and 37, and similarly has failed to establish 
a prima facie case of unpatentability for claim 36 that depends on claim 1 and claim 
43 that depends on claim 37, and which recite further specific elements that have no 
reasonable correspondence to the references. 

Claim 36 depending on independent claim 25 proposes that, in addition to 
storing both the application-specific value and the general value which are each 
exchangeable between each other in the financial transaction, all of the application- 
specific value is exchanged in a transaction, new application-specific value is 
automatically loaded, at least a portion of which is exchanged to complete the 
financial transaction. Claim 43 proposes that, in addition to storing both the 
application-specific value and the general value which are both compatible for use in 
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a transaction and are each exchangeable between each other in the financial 
transaction, a predetermined amount of application-specific value is added to the 
smart card if a sufficient amount of the application-specific value does not exist 
which exchanging a transaction amount of value that is at least a portion of the 
application-specific value or the general value. 

Taskett does not remedy the deficiencies of Carlisle, Derksen, Gungl, and 
Electronic Payment Systems. On the contrary, Traskett recites a prepaid phone card 
having application-specific value (specific for making phone calls) and a prepaid 
instrument, credit or debit card that can be transferred to the phone card to replenish 
its account balance. However, while funds from the prepaid instrument, credit or 
debit card may be exchangeable in the sense of transferring value in and out, the 
prepaid phone card with its application-specific value is not exchangeable because it 
can only receive and convert funds from the prepaid instrument, credit or debit card 
into value specific for the application of making phone calls, whereas it cannot 
convert the specific value for phone charges back into funds for the prepaid 
instrument, credit or debit card. 

Consequently, Carlisle, Derksen, Gungl, Electronic Payment Systems, and/or 

Traskett, either alone or in combination with one another, do not teach or suggest the 

required combinations of limitations proposing that all of the application-specific 

value stored on the smart card and exchangeable with the general value also stored in 

the smart card is exchanged in a transaction, new application-specific value is 

automatically loaded, at least a portion of which is exchanged to complete the 

financial transaction, as recited in claim 36. Neither Carlisle, Derksen, Gungl, 

Electronic Payment Systems, nor Traskett, either alone or in combination with one 

another teach or suggest the required combinations of limitations proposing that a 

predetermined amount of application-specific value is added to the smart card if a 

sufficient amount of the application-specific value does not exist when exchanging a 

transaction amount of value that is at least a portion of the application-specific value 

or the general value both stored on the smart card and exchangeable between each 

other in the financial transaction, as recited in claim 43. 
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Because the cited references, either alone or in combination, do not teach or 
suggest claims 36 or 43, the Examiner has failed to establish the required prima facie 
case of unpatentability. See In re Rovka , 490 F.2d 981, 985 (C.C.P.A., 1974) 
(holding that a prima facie case of obviousness requires the references to teach all of 
the limitations of the rejected claim); See also MPEP §2143.03. 
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(8) Claims Appendix 

1 . (previously presented) A system for performing a financial transaction, 
comprising: 

a first electronic application for storing application-specific value on a 
transaction card; 

a second electronic application for storing general value on the transaction 
card; and 

a transaction application associated with at least said first electronic 
application for performing a value exchange, wherein said application-specific value 
and said general value are each exchangeable between each other in said transaction 
application; and 

wherein said application-specific value and said general value are each 
compatible within said system for performing said financial transaction. 

2. (cancelled) 

3. (original) A system as recited in claim 1, further comprising: 

at least one communication interface for transferring at least one of said 
application-specific value and said general value to or from said first electronic 
application and said second electronic application, respectively. 

4. (original) A system as recited in claim 3, wherein said at least one 
communication interface comprises a contactless interface. 

5. (original) A system as recited in claim 1 , wherein said financial 
transaction utilizing said first electronic application is formatted for utilization with a 
settlement system associated with said second electronic application. 
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6. (original) A system as recited in claim 1, wherein said financial 
transaction comprises a transfer of at least a portion of each of said application- 
specific value and said general value. 

7. (original) A system as recited in claim 1, wherein said financial 
transaction comprises a transfer of at least a portion of one of said application-specific 
value and said general value. 

8. (original) A system as recited in claim 1 embodied in a smart card 
comprising a memory for storing said first electronic application and said second 
electronic application. 

9. (original) A system as recited in claim 8, further comprising: 

a transaction application associated with said first application for performing a 
value exchange associated with said financial transaction, wherein said application- 
specific value and said general value are each compatible with said transaction 
application, and wherein said transaction application is stored in said memory of said 
smart card. 

10. (original) A system as recited in claim 8, further comprising a first 
terminal for loading at least one of said first electronic application and said second 
electronic application onto said memory. 

11. (original) A system as recited in claim 8, further comprising a second 
terminal for adjusting the amount of at least one of said application-specific value and 
said general value based upon said financial transaction. 

12. (original) A system as recited in claim 1 1 , further comprising: 

a transaction application for performing a value exchange associated with said 
financial transaction, wherein said application-specific value and said general value 
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are each compatible with said transaction application, and wherein said transaction 
application is stored in said second terminal. 

13. (original) A system as recited in claim 1, further comprising: 

an auto-load application for loading new application-specific value into said 
first electronic application. 

14. (original) A system as recited in claim 13, wherein said new application- 
specific value is exchanged from said general value. 

1 5. (original) A system as recited in claim 13, wherein said new application- 
specific value is exchanged for a debit to an account selected from the group 
consisting of a checking account, a savings account, a credit account, a debit account, 
and a loan account. 

16. (original) A system as recited in claim 1 , further comprising: 

an auto-load application for loading new general value into said second 
electronic application. 

17. (original) A system as recited in claim 16, wherein said new general 
value is exchanged for a debit to an account selected from the group consisting of a 
checking account, a savings account, a credit account, a debit account, and a loan 
account. 

1 8. (previously presented) A smart card for performing a financial 
transaction, comprising: 

a first application for storing application-specific value on said smart card; 

a second application for storing general value on said smart card; 
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wherein said application-specific value and said general value are each 
compatible for performing said financial transaction; and 

wherein said application-specific value and said general value are each 
exchangeable between each other, 

19. (previously presented) A smart card as recited in claim 18, wherein said 
financial transaction utilizing said first application is formatted for utilization with a 
settlement system associated with said second application. 

20. (original) A smart card as recited in claim 18, wherein said financial 
transaction comprises a transfer of at least a portion of each of said application- 
specific value and said general value. 

21. (original) A smart card as recited in claim 18, further comprising: 

at least one communication interface coupled with at least one of said first 
application and said second application for transferring at least one of said 
application-specific value and said general value. 

22. (original) A smart card as recited in claim 21 , wherein said at least one 
communication interface comprises a contactless interface. 

23. (original) A smart card as recited in claim 1 8, further comprising: 

a memory for storing said first application and said second application as 
software components. 

24. (original) A smart card as recited in claim 23, further comprising: 

at least one communication interface coupled with at least one of said first 
application and said second application for transferring at least one of said 
application-specific value and said general value. 
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25. (previously presented) A method for performing a financial transaction 
with a smart card, comprising: 

storing application-specific value in a first electronic application on said smart 

card; 

storing general value in a second electronic application on said smart card; 

performing a value exchange associated with the financial transaction, wherein 
the application-specific value and the general value are each exchangeable between 
each other in the financial transaction. 

26. (original) A method as recited in claim 25, further comprising 
exchanging at least a portion of one of the application-specific value and the general 
value to perform the transaction. 

27. (original) A method as recited in claim 25, further comprising 
exchanging at least a portion of both the application-specific value and the general 
value to perform the transaction. 

28. (original) A method as recited in claim 25, further comprising formatting 
the financial transaction performed with application-specific value for utilization with 
a settlement system associated with the second electronic application. 

29. (original) A method as recited in claim 25, further comprising 
transferring at least one of the application-specific value and the general value 
through a communication interface in communication with at least one of the first 
electronic application and the second electronic application. 

30. (original) A method as recited in claim 29, wherein the at least one 
communication interface comprises a contactless interface. 
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31. (previously presented) A method as recited in claim 25, wherein storing 
the application-specific value in the first electronic application comprises storing the 
application-specific value in a memory on said smart card. 

32. (previously presented) A method as recited in claim 25, wherein storing 
the general value in the second electronic application comprises storing the general 
value in a memory on said smart card. 

33. (original) A method as recited in claim 25, wherein performing a value 
exchange comprises utilizing a transaction application to perform the financial 
transaction. 

34. (previously presented) A method as recited in claim 33, wherein utilizing 
a transaction application comprises utilizing a transaction application stored in a 
memory on said smart card. 

35. (original) A method as recited in claim 33, wherein utilizing a 
transaction application comprises utilizing a transaction application stored in a 
transaction terminal. 

36. (original) A method as recited in claim 25, further comprising: 

exchanging all of the application-specific value; 

automatically loading new application-specific value; and 

exchanging at least a portion of the new application-specific value to complete 
the financial transaction. 

37. (previously presented) A method for performing a financial transaction 
for exchanging an amount of value between a smart card and a corresponding device, 
comprising: 
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providing application-specific value and general value on the smart card, 
where both the application-specific value and general value are compatible for use in 
performing the financial transaction and wherein the application-specific value and 
the general value are each exchangeable between each other; and 

exchanging a transaction amount of value between the smart card and the 
corresponding device, where the transaction amount of value is at least a portion of 
one of the application-specific value and the general value. 

38. (original) A method as recited in claim 37, further comprising 
establishing a communication channel between the smart card and the corresponding 
device. 

39. (original) A method as recited in claim 38, wherein the communication 
channel comprises a network selected from the group consisting of a merchant point- 
of-sale network and the Internet. 

40. (original) A method as recited in claim 37, further comprising: 

inquiring about the availability of a sufficient amount of application-specific 
value to perform the financial transaction; and 

exchanging the sufficient amount of application-specific value if the sufficient 
amount exits. 

41 . (original) A method as recited in claim 40, further comprising: 

determining a deficient amount of value if the sufficient amount of 
application-specific value does not exist; 

inquiring about the availability of the deficient amount of value in general 
value; and 
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exchanging the deficient amount of value in general value. 

42. (original) A method as recited in claim 41, further comprising converting 
the deficient amount of value in general value to a deficient amount of value in 
application-specific value. 

43. (previously presented) A method as recited in claim 37, further 
comprising adding a predetermined amount of application-specific value to the smart 
card if a sufficient amount of the application-specific value does not exist. 

44. (original) A method as recited in claim 37, further comprising tracking 
the usage of said application-specific value and said general value associated with the 
financial transaction in order to determine a reward. 

45. (previously presented) A system for performing a financial transaction, 
comprising: 

a smart card having a memory for storing a first application having 
application-specific value and a second application having general value, wherein 
said application-specific value and said general value are compatible for performing 
said financial transaction and wherein said application-specific value and said general 
value are each exchangeable between each other and are secured by encryption on 
said smart card; and 

a purchase device for removing value from said smart card, said purchase 
device comprising a first purchase key for use in removing application-specific value 
from said first application and a second purchase key for use in removing general 
value from said second application, wherein both said first and second purchase keys 
are security mechanism for accessing encrypted information, and wherein said 
purchase device is adapted for communication with said smart card to transfer at least 
one of said application-specific value and said general value in said financial 
transaction. 
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46. (original) A system as recited in claim 45, wherein said first application 
generates a first set of transaction information, including said application-specific 
value, and said second application generates a second set of transaction information, 
including said general value, for use in said financial transaction, wherein said first 
set of transaction information is formatted for processing like said second set of 
transaction information. 

47. (original) A system as recited in claim 45, further comprising a funding 
source for receiving funds in exchange for transferring at least one of said 
application-specific value and said general value to said smart card. 

48. (original) A system as recited in claim 45, further comprising a 
settlement system for accounting for the flow of application-specific value and 
general value among said smart card and said purchase device in order to settle said 
financial transaction. 
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(9) Evidence Appendix 

None. 
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(10) Related Proceedings Appendix 

None. 
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CONCLUSION 



The undersigned representative respectfully submits that this application is in 
condition for allowance, and such disposition is earnestly solicited. Applicants 
respectfully request that the final rejections by the Examiner be reversed. Please 
charge any shortage in fees due in connection with the filing of this paper, including 
extension of time fees, to Deposit Account 50-1458, and please credit any excess fees 
to such deposit account. 



Respectfully submitted, 



Date: l(^f°l 

KILPATRICK STOCKTON LLP 
607 14th Street, N.W., Suite 900 
Washington, D.C. 20005 
(202) 508-5800 
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